1. Field of the Invention
The present invention relates generally to methods and systems for accessing data in databases and, more particularly, to systems, methods, software products, and software product components used to develop software applications that access data in relational databases.
2. Related Art
The development and maintenance of client-server software systems can become extremely difficult when client software applications that access a database are dependent on the database schema. As the number of client applications increases, the amount of work required to implement a change of schema increases dramatically. Not only do all the affected client applications have to be changed, but it generally also is necessary to track all the dependencies between clients and the database so as to ensure that all the required changes are accounted for. Moreover, once the schema change is complete, it typically is necessary to recompile and redistribute all the affected client applications. As the number of client applications increases, these tasks can become complex and burdensome.
A variety of approaches have been developed for isolating client applications from the database schema so that certain types of schema changes can be made without requiring that the client applications be revised. For instance, some commercially available database products include user interfaces that implement a technique sometimes referred to as xe2x80x9cdata binding.xe2x80x9d Data binding involves the use of SQL (Structured Query Language) commands to declaratively map server-side data into the user interface software component without requiring that the programmer manage details of the operation of the user interface component. Data binding is popular because it is simple, easy to use, relatively standard, and can be used casually without requiring any support outside the user-interface component.
The use of data-binding interfaces suffers, however, from a number of disadvantages. One is that result sets generally must be updateable, which may impose serious limitations on the design of the user interface component. Another disadvantage is that the SQL code responsible for the data binding generally is stored in the client application. Thus, when the data bindings are changed due to a change in the database scheme, the client application must be recompiled and redistributed. Moreover, many data-bound interface components employ a single SQL command to manage all of their operations, thereby significantly limiting functionality. Even if more than one SQL command is used, the functionality is limited by the scope of the SQL commands employed. Yet another disadvantage is that it typically is difficult to change the behavior of data-bound interface controls at runtime.
Another approach to isolating client applications from the database schema is to use views and stored procedures to map data and operations on the data from the client to the server, with applications accessing the database only through these objects. The views-and-stored-procedures approach generally offers the advantage over data-binding approaches of maintaining functionality on the server side. However, there are a number of disadvantages to the views-and-stored-procedures approach. For example, it typically is difficult to maintain stored procedures, as they contain no information about their intended use, or indeed, whether they are used at all. A typical database will soon become cluttered with unused code, creating a significant drain on maintenance efforts. Another disadvantage is that stored procedures and views generally are accessed by name, making naming problems likely as the number of clients increases or when clients are moved from one database to another. Moreover, all the available stored procedure names generally are not known in advance, and it typically is difficult for client applications to change their behavior at runtime without having this information available. Yet another disadvantage is that, unless regularly recompiled, it is possible for stored procedures to become invalid and therefore to fail without apparent explanation. Generally, the use of views also invites dependencies on the ability to update a view. This capability often cannot be guaranteed even as the result of seemingly minor schema changes.
Yet another approach has been used by database developers and has also been incorporated into commercial software products that often are referred to as xe2x80x9cmiddleware.xe2x80x9d These products provide an object-oriented view of the database so that compatibility with the client applications is maintained even as the underlying database changes. Middleware addresses a number of the problems associated with data binding by re-mapping the database schema to an invariant, often object-oriented form. Also, some middleware products offer the additional features of transaction management and integration of multiple data sources. Moreover, some middleware systems provide a view of the database that reduces the mismatch between the relational data structures in a database and the pointer-based data structures most often used in programming languages. However, conventional middleware products also generally have significant disadvantages when used as a mechanism for schema independence. For example, the queries they employ often are cumbersome and difficult to maintain, requiring a relatively formal configuration management strategy. Due to the complexity of configuring the middleware to particular applications, they generally are very expensive, whether purchased commercially or developed in-house. In addition, some middleware products are tied to a specific language, such as Java or C++, thereby dictating how client applications must be developed.
Systems, methods, and products are described for developing, modifying, or maintaining client applications that access data in one more databases. For convenience, these one or more databases may sometimes be referred to hereafter singly or in the aggregate as the xe2x80x9ctarget database.xe2x80x9d The target database typically, but not necessarily, is a relational database. Systems in accordance with the present invention may hereafter be referred to for convenience as xe2x80x9cschema-isolated systems.xe2x80x9d Reference may occasionally be made in the detailed description or the figures to a particular implementation of a schema-isolated system, arbitrarily referred to convenience as the xe2x80x9cPantheonxe2x80x9d system or architecture. It will be understood that these reference although made simply to xe2x80x9csystemsxe2x80x9d for convenience, generally include methods and products in accordance with the present invention.
Embodiments of the present invention provide various combinations of advantages over conventional systems, methods, or products for developing, modifying, or maintaining applications that access databases. With respect to conventional approaches using data-binding interfaces, for example, the SQL code responsible for the binding in accordance with some implementations of a schema-isolated system is stored in the target database, rather than in the client application. Thus, when the bindings are changed, there is no need to recompile and redistribute the client application. Also, schema-isolated system components may have an unrestricted number of query templates. Thus, they offer greater functionality as compared with approaches employing conventional data-binding interfaces. For instance, optional features may be provided that that the user need not employ. Similarly, a schema-isolated system typically employs templates that update data in the target database. The schema-isolated system thus can perform arbitrarily complex operations using procedural code. This capability generally is not possible with the pure SQL used by most data-bound controls. Yet another advantage is that, as noted, it typically is difficult to change the behavior of data-bound interface controls at runtime. In contrast, the multiple configurations available to a schema-isolated system component makes it easy to implement and coordinate runtime dynamism of this type.
Schema-isolated systems also provide important advantages as compared to middleware products. Contrary to the case with respect to middleware products, there are many strategies and languages that can be used to create a client application that is consistent with a schema-isolated system.
Advantages are also achieved as compared to the stored-procedure-and-views approaches noted above. For example, a schema-isolated system typically uses globally unique identifiers (GUIDs) to access objects that might suffer from namespace collisions. Also, schema-isolated system components typically do not use updateable result sets; rather, they perform updates using separate SQL commands. Further, schema-isolated system client applications may determine available configurations at runtime by interrogating tables inserted by the schema-isolated system into the target database. For convenience, these tables, as further described below, are generally referred to as xe2x80x9cmiddleware tables.xe2x80x9d Another advantage is that schema-isolated system components compile their SQL code the first time it is executed in each session.
These and other advantages are realized by virtue of various attributes of the schema-isolated system, such as the organization of SQL queries in accordance with the following four criteria: syntax; configuration (also sometimes referred to as semantics); component usage; and application usage. In some implementations, xe2x80x9csyntaxxe2x80x9d refers, for example, to the number, names, and types of columns in a tabular data set. In some implementations, xe2x80x9cconfigurationxe2x80x9d may refer to the intended function of a datum in what is referred to herein as compatibility data. By compatibility data is meant data relating one or more client-application data requests with one or more corresponding target-database data capabilities. The compatibility data may include an SQL query. As is well known in the art, there are numerous variations and procedural extensions of SQL, such as Transact-SQL, PL/SQL, and others. The term xe2x80x9ccomponent usagexe2x80x9d is used herein to refer to the ability of a component to make use of a compatibility datum. For convenience, the criteria of syntax, configuration, and component usage may sometimes generally and collectively be referred to herein as xe2x80x9capplication-usage-independentxe2x80x9d criteria.
As described in greater detail below, a benefit of this organization is the ability to provide systematic dependency tracking between database tables and application usage, as well as the ability to dynamically reconfigure general purpose applications or application components to perform a variety of different tasks. There are many practical implementations in which these advantages are substantial. For example, if the target database schema is changed, it is not necessary to review every client application for dependencies on the affected tables. Rather, a user may simply query a portion of the database including the middleware tables in order to determine which components in which applications, if any, require adjustment. The adjustments may then be made without re-deploying the application. Rather, the user may simply adjust the compatibility data that are used. As another example, it is possible to create components like scatter plot controls or dendrogram viewers, and connect them to different data at runtime simply by changing the xe2x80x9cconfigurationxe2x80x9d of the components. Different configurations for these controls use the same syntax, but the configuration determines the meaning of what the component is doing.
Advantages of the schema-isolated system also are achieved due to the storage of compatibility data in a middleware table, retrieved at runtime by the application using them. In particular, advantages are achieved by organizing SQL statements according to explicit semantic criteria. Although some of this information could be inferred from conventional views by using the system catalog, this would be a purely syntactic organization and would not typically provide clues as to the semantics. In addition, conventional view storage does not permit direct querying of which applications use which view. Yet another advantage is due to the systematic, server-side representation of xe2x80x9cselection statexe2x80x9d in client applications, as described below. Scientific applications often can be made more powerful by the use of xe2x80x9cshared selection state.xe2x80x9d Although some conventional applications may employ aspects of the shared selection concept, they do not fully realize the potential of this approach. For example, the schema-isolated system allows different selection types to exist concurrently, and maintains the selection state on the server so that it can be shared by components within applications, components in different applications, or components running on different client workstations.
Advantages of the schema-isolated system also are achieved due to the use of advanced data binding to permit rapid construction of applications using COM components. Also, the schema-isolated system enables self-registration of components. These further advantages are also described in greater detail below.
More specifically, in one embodiment the invention is directed to a system (referred to for convenience only as a schema-isolated system) for developing, modifying, or maintaining at least one client application that accesses data in at least one target database. The system includes a middleware-table inserter that inserts at least one middleware table into the target database. It will be understood that the term xe2x80x9cinsertxe2x80x9d is used broadly in this context to refer to any of a variety of known techniques for including or adding information to a table. Also, the term xe2x80x9ctablexe2x80x9d is used broadly to refer to any known technique or method for storing and organizing data. The middleware table includes a set of compatibility data relating one or more client-application data requests with one or more corresponding target-database data capabilities. The system also includes a data communication component that receives a client-application data request from the client application, and, based on at least a first datum of the set of compatibility data, provides to the client application the one or more target-database data capabilities corresponding to the client-application data request. In this system, the first compatibility datum relates the one or more client-application data requests with the one or more corresponding target-database data capabilities based, at least in part, on an application-usage-independent criterion. The term xe2x80x9capplication-usage-independent criterionxe2x80x9d means a criterion based, at least in part, on a syntax criterion, a configuration or semantics criterion, or a component usage criterion. The first compatibility datum may also relate the one or more client-application data requests with the one or more corresponding target-database data capabilities based, at least in part, on an application usage criterion.
In some implementations, the first compatibility datum includes at least one SQL query. The target database may be a relational database.
In other embodiments, the invention is directed to a method for developing, modifying, or maintaining at least one client application that accesses data in at least one target database. The method includes the steps of: inserting at least one middleware table into the target database, wherein the middleware table includes a set of compatibility data relating one or more client-application data requests with one or more corresponding target-database data capabilities; receiving a client-application data request from the client application; and, based on at least a first datum of the set of compatibility data, providing to the client application the one or more target-database data capabilities corresponding to the client-application data request. The first compatibility datum relates the one or more client-application data requests with the one or more corresponding target-database data capabilities based, at least in part, on an application-usage-independent criterion. In yet other embodiments, the invention is directed to a computer program product that, when executed on an appropriate computer platform (which may be a server, workstation, personal computer, or any other type of computer, and may include distributed computer systems) performs a method including the method steps just described.
The above embodiments are not necessarily inclusive or exclusive of each other and may be combined in any manner that is non-conflicting and otherwise possible, whether they be presented in association with a same, or a different, aspect of the invention. The description of one embodiment is not intended to be limiting with respect to other embodiments. Also, any one or more function, step, operation, or technique described elsewhere in this specification may, in alternative embodiments, be combined with any one or more function, step, operation, or technique described in the summary. Thus, the above embodiments are illustrative rather than limiting.